1. Field of the Invention
The present invention relates in general to electronic circuits and in particular to circuits used in wireless electronic input/output devices such as human interface devices (HIDs) that send and receive serial information into and from a computer using a compressed packet to reduce the consumption of power needed by a battery operated, wireless input/output device.
2. Description of the Related Art
The following descriptions and examples are not admitted to be prior art by virtue of their inclusion within this section.
A typical personal computer (PC) generally comprises a processing unit or microprocessor, memory, and input/output ports. A processing unit can have functional units that receive instructions from, for example, memory and operate on those instructions to produce results stored back into the memory, or dispatched to an input/output device connected to the port. There are many types of processors available on the market and are generally classified based on the instruction sets they are capable of handling. Memory can be defined generally as system memory or magnetic/optical mask storage memory. System memory is configured closer to the processing unit and is oftentimes referred to as semiconductor memory. The input/output port operates as a buffer and bus bridge to connect input/output devices to, for example, the system bus to which the processing unit is either directly or indirectly connected.
There are numerous types of input/output ports currently operative in the marketplace. For example, the input/output ports can be classified as either a serial port or a parallel port. If a PC includes a serial port, it is generally beneficial to communicate to the PC using a universal serial bus (USB). USB is a communication architecture that gives a PC the ability to interconnect with a variety of devices using a simple four-wire cable. USB has gained widespread acceptance where USB protocols can configure devices at startup for plug-and-play relative ease-of-use. When a USB peripheral is plugged into a USB port on a PC, the PC can auto-detect and auto-configure that peripheral device. In most cases, there is no user intervention required. The original USB specification has evolved over time to meet the needs of the industry, resulting in two versions available today. The USB interface can be described in various versions, all of which are available through the Internet at www.usb.org.
The USB devices that can be configured at startup or at runtime can be broken into various device classes, for example. Each device class defines a common behavior and protocols for those devices. A popular USB device class includes the human interface device (HID) class. As defined herein, the HID class consists primarily of devices (referred to herein as HID devices or simply devices) that are used by humans to control the operation of a computer system, such as a PC. Typical examples of HID class devices include: keyboards and pointing devices, front-panel controls, controls that might be found on devices such as telephones, VCR remote controls, games or simulation devices, and devices that may not require human interaction but provide data in a similar format to HID class devices (e.g., barcode readers, thermometers, or volt meters). A description of all of the various examples of HID class devices is provided in the usb.org website, under the definition of device class for HIDs and HID usage tables.
The USB protocol defines the structure by which HID devices send and receive data. For example, HID devices transmit and receive data in data packages called “reports.” Reports contain two different types of data generated by HID devices: buttons and values. While the various types of data are generally classified as “data items,” each data item is generated by a control, such as a key, slider, single access of a joystick, button, knob, switch, etc. While a button-type data item is binary (i.e., either the button is depressed or not), a value-type data item can have a range of values, usually indicating the position of a pointer device as opposed to, for example, whether a button on that pointer device has been depressed. While HID devices usually generate input data items, reports can also be received by HID devices. The reception of reports by an HID device can, for example, enable the PC to control an LED, speaker volume, or other output devices on an HID device.
Each control has an associated “usage” specified by the HID device manufacturer or, alternatively, programmed into the HID device during plug-and-play or startup. When the HID device is being auto-detected and auto-configured, the HID device can receive from a client (or host) an HID “report descriptor.” A report descriptor will specify the reports generated by the HID device. Thus, for each report, the report descriptor describes the arrangement and formatting of the data items contained in the report, as well as the usages associated with each data item. Thus, the report can be represented as a set of bytes within a packet, each byte arranged and formatted according to the report descriptor to define certain usages for those bytes. Accordingly, one or more bytes within the report represents a data item usable by the PC. Any application program that uses HID report data must first parse the associated report descriptor to determine how to interpret the individual reports, and how to find the data items within the reports.
Typical USB HID reports from a keyboard are arranged and formatted by the report descriptor as having a fixed-length, 8-byte sequence of bits placed within a packet sent from the HID keyboard to the PC. The HID keyboard packet can allow possibly up to six simultaneous key presses, presses on a modifier key (e.g., a control, shift, alt key, etc.), and also contain a reserve byte to thereby represent all 8 bytes of the report. A conventional HID boot protocol keyboard packet is a fixed-length 8-byte packet, whereas a conventional HID mouse packet is a fixed-length 4-byte packet.
Difficulties arise, however, when attempting to send all fields of fixed-length keyboard and mouse packets across a wireless medium. For example, there may be several byte fields within the HID report that will be transmitted, even though many of those fields are not used in a typical packet. For example, a typical keyboard most likely encounters only a single key press, even though the HID keyboard report will transmit up to six simultaneous fields allocated for six simultaneous key presses. Requiring a wireless keyboard to transmit the entire 8-byte report, even though there is only a single byte of data in the report, significantly impacts the battery-life of the wireless keyboard. The typical mouse usage is movement only. Thus, the report should contains X and Y deltas, and not the unused Z delta (scroll wheel) or button presses. Therefore, the 4-byte mouse report should only contain two bytes of data since, in most instances, the only prevalent usage is the movement in the X and Y delta directions. Requiring the mouse to transmit the entire 4-byte report even though no button(s) are being actuated, nor is the scroll wheel being moved, significantly impacts the battery-life of the wireless mouse.
It would be desirable to have a system and method for compressing an HID report into only those bytes currently implemented by the HID device, and to discard and not transmit all bytes of the report that are not being implemented. In addition, it would also be desirable to arrange the fields within the report so that the type of report being conveyed can be determined as quickly as possible and, preferably, within one byte of the report. Instead of sending non-used reserve bytes or bytes reserved for concurrent key actuation or modified key actuation, it would be of benefit to simply not send such bytes in order to formulate a variable-size and relatively small size, compressed packet that consumes lessened energy for transmission thereof.